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DETAILED ACTION 

Claims 1-2, 4-24 and 26-41 are pending. 
Claim 7, 15, 34 and 35 are allowed. 
Claims 9, 12-14, 16-19, 21-24, 31 and 33 are objected to. 
Claims 1-2, 4-6, 8, 10, 11, 20, 26-30, 32 and 36-41 are rejected. 
Claims 3 and 25 are cancelled. 

Claim Objections 

1 . Claim 20, as amended is objected to because of the following informalities: 
Claim 20 refers to "third signature" without referring to "second" signature. It is unclear 
as to why claim limitation jumps from "a signature" in claim 1 to "third signature" in 
claim 20 without referring to "second" signature Appropriate correction is required. 

2. Claims 21 -24 has similar issues. 

Claim Rejections - 35 USC § 102 

3. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent. 

4. Claims 26-30, 40 and 41 are rejected under 35 U.S.C. 102(a) as being 
anticipated by Buch et al. (US PAT PUB 2003/0217165, hereinafter Buch). 

Regarding claim 26, Buch teaches computer readable storage medium having 
computer executable instructions (see paragraphs 16 and 17) for performing steps for 
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processing messages in a pool of servers (see paragraph 24 and 25 caller and callee 
server) having a first server and a second server which are constructed and arranged to 
be interchangeably used to process messages in the same dialog (see figure 2 and 
paragraph 24 and 25 caller and callee server inherently constructed and arranged to be 
interchangeably used to process messages in the same dialog), the steps comprising: 
identifying, at the first server (see paragraph 25), a public key (see paragraph 26) and a 
private key (see paragraph 27); receiving, at the first server, a first message including a 
first header (see paragraph 28 receive message and paragraph 34); generating a 
session key (see paragraph 28 private-public key); encrypting the session key with the 
private key (see paragraph 28); generating, with the public key, a key signature (see 
paragraph 28 private- public key) based on the encrypted session key (see paragraph 
27-28); inserting the key signature into the first header (see paragraph 34 and 42). 

Regarding claim 27, Buch teaches further comprising: identifying, at the second 
server (see paragraph 25), the public key and the private key (see paragraph 28 
private-public key); receiving, at the second server, a second message including a 
second header, the second header comprising the key signature (see paragraph 28); 
decrypting the key signature to determine the session key (see paragraph 28). 

Regarding claim 28, Buch teaches further comprising: verifying at least a portion 
of the second message with the session key (see paragraphs 44, 45). 

Regarding claim 29, Buch teaches the first message is a Session Initiation 
Protocol (SIP) message (see paragraph 23). 
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Regarding claim 30, Buch teaches the first server is a proxy server (see 
paragraph 25). 

In regards to claim 40, Buch teaches a method performed by a SIP node routing 
a SIP message between a first SIP node and a second SIP node (paragraph 0024, By 
way of example, FIG. 2 shows an exemplary session initiation operation in which a user 
76 (e.g., "Ann") of a SIP client 72 wants to initiate a communication session with 
another user 80 (e.g., "Bob"). To that end, the SIP client 72 sends an INVITE request 
message 82 that identifies Bob as the intended recipient for the INVITE request), the 
method comprising: receiving the SIP message from the first SIP node (paragraph 
0024, By way of example, FIG. 2 shows an exemplary session initiation operation in 
which a user 76 (e.g., "Ann") of a SIP client 72 wants to initiate a communication 
session with another user 80 (e.g., "Bob"). To that end, the SIP client 72 sends an 
INVITE request message 82 that identifies Bob as the intended recipient for the INVITE 
request), the SIP message including a first SIP routing header added to the SIP 
message by the first SIP node, the first SIP routing header identifying the first SIP node 
(see figure 2, From field and paragraph 0024, By way of example, FIG. 2 shows an 
exemplary session initiation operation in which a user 76 (e.g., "Ann") of a SIP client 72 
wants to initiate a communication session with another user 80 (e.g., "Bob"). To that 
end, the SIP client 72 sends an INVITE request message 82 that identifies Bob as the 
intended recipient for the INVITE request); generating a digital signature of the first SIP 
routing header; adding the digital signature to the SIP message; and forwarding the SIP 
message to the second SIP node (paragraphs 0026-0030). 



Application/Control Number: 10/815,232 Page 5 

Art Unit: 2419 

In regards to claim 41, Buch teaches adding, by the SIP node, a second SIP 
routing header comprising information identifying the SIP node (paragraph 0024, By 
way of example, FIG. 2 shows an exemplary session initiation operation in which a user 
76 (e.g., "Ann") of a SIP client 72 wants to initiate a communication session with 
another user 80 (e.g., "Bob"). To that end, the SIP client 72 sends an INVITE request 
message 82 that identifies Bob as the intended recipient for the INVITE request), 
wherein the adding the digital signature comprises appending the digital signature to the 
second SIP routing header (paragraphs 0026-0030, 0034 and 0044). 



Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 
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3. Claims 1 , 2, 4, 5, 6 and 8 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Buch et al. (US2003/0217165, hereinafter Buch) in view of Shores et 
al. (US PAT 7142537, hereinafter Shores). 

Regarding claim 1, Buch discloses a method of processing a Session Initiation 
Protocol (SIP) message comprising: receiving a SIP request (see paragraph 24 invite 
request message) at a SIP node (see paragraph 24 SIP client user/eg., "Ann"), the SIP 
request including a message header (see paragraph 0024, an INVITE request message 
82 that identifies Bob as the intended recipient for the INVITE request paragraph 34, 
header of the SIP request 82, and paragraph 0036, 0041 header); generating, a 
signature based upon at least a portion of the message header (see paragraphs 0038- 
0040); (c) generating a SIP node header entry (see paragraphs 0038-0040); and (d) 
inserting the signature into the SIP node header entry (see paragraphs 0038-0040). 

Buch does not explicitly teach message header indicating data indicative of 
network routing locations; editing the data at the SIP node and generating header based 
upon at least a portion of the message header including the edited data. 

Shores in the same field of endeavor teaches message header indicating data 
indicative of network routing locations (figure 2, elements 45 and 47); editing the data at 
the SIP node and generating header based upon at least a portion of the message 
header including the edited data (figure 2 and 6, column 6 lines 40-47, the From header 
84 is extended by field 85 which is a user id field. The user id field 85 is the same field 
as the user id field 46 of From header 45 and is explained above with reference to FIG. 
2. Similarly, the To header 86 is extended by field 87 which is a user id field. The user 
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id field 86 is the same field as the user id field 48 of To header 47 and is explained 
above with reference to FIG. 2). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch's system and method the steps of message header 
indicating data indicative of network routing locations; editing the data at the SIP node 
and generating header based upon at least a portion of the message header including 
the edited data as suggested by Shores. The motivation is that (as suggested by 
Shores, column 1 lines 23-27) such method of editing and extending protocol 
standardized messages, enables networks of a peculiar variety or an older type and are 
not suitable for using the IETF standards protocol, to reliably, securely and seamlessly 
communicate with one another. 

Regarding claim 2, Buch teaches the SIP node header entry is an echoed header 
(see paragraphs 23 and 37 response message). 

Regarding claim 4, Buch does not explicitly teach SIP node header entry being 
VIA header. 

Shores in the same field of endeavor teaches SIP node header entry being VIA 
header (Figure 2, 4 and 5-10, VIA header). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch's system and method the steps of SIP node header 
entry being VIA header as suggested by Shores. The motivation is that, the VIA header 
field value typically includes a branch parameter; the branch parameter which is unique 



Application/Control Number: 10/815,232 Page 8 

Art Unit: 2419 

across space and time for calls initiated by a client device, is used to reliably and 
efficiently identify the call created by a client device. 

Regarding claim 5, Buch teaches receiving a SIP response at the SIP node in 
reply to the SIP request (see paragraph 23), a first received signature; and verifying the 
first received signature (see paragraphs 23 and 26). 

Buch does not explicitly teach SIP response being VIA header. 

Shores in the same field of endeavor teaches SIP node header for 
request/response being VIA header (Figure 2, 4 and 5-10, VIA header). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch's system and method the steps of SIP node header 
entry being VIA header as suggested by Shores. The motivation is that, the VIA header 
field value typically includes a branch parameter; the branch parameter which is unique 
across space and time for calls initiated by a client device, is used to reliably and 
efficiently identify the call created by a client device. 

Regarding claim 6, Buch teaches verifying includes generating a verification 
signature (see paragraphs 23 and 26), the SIP response and comparing the verification 
signature with the first received signature (see paragraph 28). 

Buch does not explicitly teach SIP response being VIA header. 

Shores in the same field of endeavor teaches SIP node header for 
request/response being VIA header (Figure 2, 4 and 5-10, VIA header). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch's system and method the steps of SIP node header 
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entry being VIA header as suggested by Shores. The motivation is that, the VIA header 
field value typically includes a branch parameter; the branch parameter which is unique 
across space and time for calls initiated by a client device, is used to reliably and 
efficiently identify the call created by a client device. 

Regarding claim 8, Buch teaches generating the signature includes generating 
a first signature based upon at least one portion of the message header (see 
paragraphs 23 and 26). 

Buch does not explicitly teach header portion being VIA header. 

Shores in the same field of endeavor teaches header portion being VIA header 
(Figure 2, 4 and 5-10, VIA header). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch's system and method the steps of SIP node header 
entry being VIA header as suggested by Shores. The motivation is that, the VIA header 
field value typically includes a branch parameter; the branch parameter which is unique 
across space and time for calls initiated by a client device, is used to reliably and 
efficiently identify the call created by a client device. 

4. Claims 11 and 20 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buch and Shores as applied to claim 1 above and further in view of Donovan (US 
PAT 6434143). 

In regards to claim 1 1 , Buch teaches generating second signature based upon at 
least a portion of header fields (paragraph 0044). 
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Buch and Shores do not explicitly teach RECORD-ROUTE and CONTACT are 
fields which are part of the header. 

Donovan in the same field of endeavor teaches RECORD-ROUTE and 
CONTACT are fields which are part of the header (Tables in columns 5-9). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch and Shores's system and method of generating second 
signature based upon at least a portion of header fields with the steps of fields being 
RECORD-ROUTE and CONTACT as suggested by Donovan. The motivation is that 
any arbitrary fields can be used to generate signature based on design choice and 
network requirement and RECORD-ROUTE and CONTACT are such two fields that can 
be used to reliably and securely generate signature. Known work (i.e. generating 
second signature based upon at least a portion of header fields) in one field of endeavor 
may prompt variations of it (i.e. fields being RECORD-ROUTE and CONTACT) for use 
in either the same field or a different one based on design incentives (i.e. design choice 
and network requirement) or other market forces/market place incentives if the 
variations are predictable to one of ordinary skill in the art. 

In regards to claim 20, Buch teaches determining fields of header of SIP request 
and generating signature includes generating third signature based upon at least a 
portion of the fields in header of SIP request (paragraph 0044). 

Buch and Shores do not explicitly teach RECORD-ROUTE is a field which is part 
of the header. 
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Donovan in the same field of endeavor teaches RECORD-ROUTE and 
CONTACT are fields which are part of the header (Tables in columns 5-9). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch and Shores's system and method of determining fields 
of header of SIP request and generating signature includes generating third signature 
based upon at least a portion of the fields in header of SIP request with the steps of field 
being RECORD-ROUTE as suggested by Donovan. The motivation is that any arbitrary 
fields can be used to generate signature based on design choice and network 
requirement and RECORD-ROUTE is such field that can be used to reliably and 
securely generate signature. Known work (i.e. generating second signature based upon 
at least a portion of header fields) in one field of endeavor may prompt variations of it 
(i.e. field being RECORD-ROUTE) for use in either the same field or a different one 
based on design incentives (i.e. design choice and network requirement) or other 
market forces/market place incentives if the variations are predictable to one of ordinary 
skill in the art. 

5. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buch 
and Shores as applied to claim 1 above and further in view of Tsuzuki et al., hereinafter 
Tsuzuki, (US2004/0246991). 

In regards to claim 10, Buch teaches generating the first signature includes 
generating the first signature based upon the header of the SIP node as described 
above. 
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Buch and Shore does not explicitly teach a message header includes a plurality 
of VIA headers and plurality of VIA headers except the VIA header of the SIP node. 

Tsuzuki in the same field of endeavor teaches a message header includes a 
plurality of VIA headers and plurality of VIA headers except the VIA header of the SIP 
node (see figure 14). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch and Shore's system and method the steps of a 
message header includes a plurality of VIA headers and plurality of VIA headers except 
the VIA header of the SIP node as suggested by Tsuzuki. The motivation is that, the 
VIA headers field value typically includes a branch parameter; the branch parameter 
which is unique across space and time for calls initiated by a client device, is used to 
reliably and efficiently identify the call created by a client device. Known work in one 
field of endeavor (i.e. VIA headers field value) may prompt variations of it for use in 
either the same field or a different one based on design incentives (used to reliably and 
efficiently identify the call created by a client device) or other market forces/market 
place incentives if the variations are predictable to one of ordinary skill in the art. 

6. Claim 37 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buch et 
al. (US2003/0217165, hereinafter Buch) in view of Bobde et al. (US PAT PUB 
2003/0005280, hereinafter Bobde). 

Regarding claim 37, Buch teaches a method of verifying a Session Initiation 
Protocol (SIP) message, the method comprising: (a) receiving a SIP response at a SIP 
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node from another SIP node, the SIP response including a message header (see 
paragraph 24 and 36); (b) identifying an echoed header in the message header (see 
paragraph 24 generate a response to request, and it is inherent for a response 
message to include a header); (c) extracting a received signature from the echoed 
header (see paragraph 26); (d) generating a verification signature based upon at least a 
portion of the message header (see paragraph 28); (e) comparing the verification 
signature with the received signature (see paragraph 28). 

Buch does not explicitly teach routing the SIP message to a next SIP node when 
the verification signature matches the received signature. 

Bobde in the same field of endeavor teaches routing the SIP message to a next 
SIP node when the verification signature matches the received signature (paragraph 
0028 and 0109). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch's system and method the steps of routing the SIP 
message to a next SIP node when the verification signature matches the received 
signature as suggested by Bobde. The motivation is that by authenticating prior to 
forwarding SIP messages enables a network to keep the communication safe and 
secure. Known work in one field of endeavor (i.e. authenticating prior to forwarding) may 
prompt variations of it for use in either the same field or a different one based on design 
incentives (keeping the communication safe and secure) or other market forces/market 
place incentives if the variations are predictable to one of ordinary skill in the art. 
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7. Claims 38 and 39 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buch and Bobde as applied to claim 37 above and further in view of Tsuzuki. 

Regarding claims 38 and 39, Buch teaches: (claim 38) the echoed header (see 
paragraph 24 generate a response to a SIP request) and (claim 39) generating a 
verification signature includes generating the verification signature (see paragraph 28) 
and disclose all the subject matter of the claimed invention with the exception of: (claim 
38) is selected from the group consisting of a VIA header, a FROM header, a TO 
header, a RECORD-ROUTE header, a CALL-ID header, and a CSeq header and 
(claim 39) based upon at least a portion of at least one of a VIA header, a CONTACT 
header, a RECORD-ROUTE header a ROUTE header, a CALL-ID header, and a CSeq 
header. 

Tsuzuki from the same or similar fields of endeavor teaches the use of the URI 
and the port number of the originating-side terminal 5A are designated by the VIA 
header indicative of a message path (see Tsuzuki paragraph 104), and more than one 
VIA headers (see Tsuzuki figure 21), To header, From header, Call ID, and CSeq (see 
Tsuzuki paragraph 104 and figure 15), via headers (see Tsuzuki figure 14 as 
correspond to claim 10) the URI and the port number of the originating-side terminal, 
and destination ID (see Tsuzuki paragraph 104 as correspond to RECORD-ROUTE and 
CONTACT), and URI portion in the invite packet (see Tsuzuki figure 14 as correspond 
to claim 13). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the VIA headers as taught by Tsuzuki in the end-to-end 
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authentication of session initiation protocol messages using certificates of Buch in order 
to prevent request looping and ensure replies take the same path as the requests. 
Known work in one field of endeavor may prompt variations of it for use in either the 
same field or a different one based on design incentives or other market forces/market 
place incentives if the variations are predictable to one of ordinary skill in the art. 
8. Claims 32 and 36 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buch in view of Donovan (US PAT 6434143). 

Regarding claims 32 and 36, Buch teaches computer readable medium having 
stored thereon a data structure (see paragraphs 16 and 17) representing a Session 
Initiation Protocol (SIP) request (see paragraph 23), the data structure comprising: a 
plurality of SIP headers (see paragraph 39 headers) comprising an echoed header (see 
paragraph 23 and 37 response message) including an address of a SIP node in a route 
for the SIP request (see paragraph 24 and 34) and data representing a digital signature 
generated by signing a portion of the SIP headers with a session key (see paragraph 
26), wherein the echoed header, is one of a group consisting of various fields of the 
header, wherein the data representing the digital signature is appended to one of the 
SIP headers (paragraphs 0042-0044). 

Buch does not explicitly teach fields in header being one of a group consisting of 
a VIA header, a FROM header, a TO header, a RECORD-ROUTE header, a CALL-ID 
header, and a CSeq header, 
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Donovan in the same field of endeavor teaches a VIA header, a FROM header, a 
TO header, a RECORD-ROUTE header, a CALL-ID header, and a CSeq header are 
fields which are part of the header (Tables in columns 5-9). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch and Shores's system and method of the data 
representing the digital signature is appended to one of the SIP headers with the steps 
of fields being a VIA header, a FROM header, a TO header, a RECORD-ROUTE 
header, a CALL-ID header, and a CSeq header as suggested by Donovan. The 
motivation is that any arbitrary fields can be used to append signature based on design 
choice and network requirement and the data representing the digital signature is 
appended to one of a VIA header, a FROM header, a TO header, a RECORD-ROUTE 
header, a CALL-ID header, and a CSeq header of the SIP headers are such fields that 
can be used to reliably and securely append signature. Known work (i.e. the data 
representing the digital signature is appended to one of the SIP headers) in one field of 
endeavor may prompt variations of it (i.e. fields being one of a VIA header, a FROM 
header, a TO header, a RECORD-ROUTE header, a CALL-ID header, and a CSeq 
header) for use in either the same field or a different one based on design incentives 
(i.e. design choice and network requirement) or other market forces/market place 
incentives if the variations are predictable to one of ordinary skill in the art. 

In regards to claim 36, Buch teaches first and second signatures being generated 
based on portions of various fields in the header of SIP header (paragraphs 0042- 
0044). 
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Buch does not explicitly teach fields in header being RECORD-ROUTE and 
CONTACT. 

Donovan in the same field of endeavor teaches RECORD-ROUTE and 
CONTACT are fields which are part of the header (Tables in columns 5-9). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to incorporate in Buch and Shores's system and method of first and second 
signatures being generated based on portions of various fields in the header of SIP 
header with the steps of fields being RECORD-ROUTE and CONTACT as suggested 
by Donovan. The motivation is that any arbitrary fields can be used to generate 
signature based on design choice and network requirement and the data representing 
the digital signature is generated from the RECORD-ROUTE and CONTACT of SIP 
headers are such fields that can be used to reliably and securely generate signature. 
Known work (i.e. first and second signatures being generated based on portions of 
various fields in the header of SIP header) in one field of endeavor may prompt 
variations of it (i.e. fields being RECORD-ROUTE and CONTACT) for use in either the 
same field or a different one based on design incentives (i.e. design choice and network 
requirement) or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 



Allowable Subject Matter 

9. Claim 7, 15, 34, 35, is allowed. 
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10. Claims 9, 1 2, 1 3, 1 4, 1 6-1 9, 21 -24, 31 and 33 are objected to as being 
dependent upon a rejected base claim, but would be allowable if rewritten in 
independent form including all of the limitations of the base claim and any intervening 
claims. 

Response to Arguments 

11. Applicant's arguments see pages 13-19 of the Remarks section, filed 7/15/2008, 
with respect to the objection to the specification have been fully considered. 

Claim 1: 

Applicant's amendment necessitated a new ground of rejection presented in this 
office action. As such any further response to Applicant's argument is moot. 
Claim 26: 

Applicant argues that Buch fails to teach "generating a session key; encrypting 
the session key with private key; generating with the public key, a key signature based 
on the encrypted session key". 

However, Examiner respectfully disagrees with the Applicant's assertion. Buch 
does indeed teach the cited limitations. Specifically, Buch teaches in paragraphs 0027- 
0028, the sender may encrypt the message with a (generated) session key, encrypt the 
session key with a public key (generated) of the intended recipient, sign the encrypted 
session key with her own private key, and include the session key in the SIP packet. 
When the callee SIP client 86 receives the SIP request message 82 containing the 
signature 100, it uses a certificate 102 of the sender associated with the private-public 
key pair of the sender to verify the digital signature 1 00 that came with the SIP request. 
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Claim 32: 

Applicant's amendment necessitated a new ground of rejection presented in this 
office action. As such any further response to Applicant's argument is moot. 
Claims 11-14, 16. 17 and 20-23: 

Applicant's amendment necessitated a new ground of rejection presented in this 
office action. As such any further response to Applicant's argument is moot. 

Conclusion 

12. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to SALMAN AHMED whose telephone number is 
(571)272-8307. The examiner can normally be reached on 9:00 am - 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Edan Orgad can be reached on (571) 272-7884. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
IS. A./ 

Examiner, Art Unit 2419 



/Edan Orgad/ 

Supervisory Patent Examiner, Art Unit 2619 



